The number of functions on a single integrated circuit chip continues to increase in concert with an increase in chip densities. These "system-on-a-chip" integrated circuits typically use a common, shared bus architecture to provide the communication link between the various devices and subsystems of the "computer system." A common bus provides a low cost communication link since it can be shared between multiple devices in the computer system. However, the linking of multiple devices to a single bus may raise concerns over maximum bus performance.
Achieving maximum bus performance may be difficult in a shared bus architecture. Factors which severely impact bus performance may include system throughput (i.e., bandwidth) and system response time (i.e., latency). For purposes of determining throughput or bandwidth, a bus transaction is a bus transaction completed by the device which is on the receiving end of the transmission. Throughput or bandwidth is the average number of bus transactions over a period of time. Response time or latency is the time it takes to complete a bus transaction for a particular device beginning with the cycle during which the device first requests the bus until the cycle that the last piece of data is transferred from the device across the bus to a second device. A device which requests access to or control of a bus and transmits and receives data across a bus may be referred to as a "master." A device which transmits or receives data across a bus and is responsive to a master may be referred to as a "slave." A slave may not request access to or control of a bus.
In order to achieve a high degree of bus performance, the throughput generally must be high while the latency generally must be low. Further, in order to achieve a high level of bus throughput, the slave preferably is never idle and, consequently, the bus is preferably never idle. In contrast, however, since latency refers to the time it takes to complete a bus transaction beginning with the cycle during which a master first requests the bus until the cycle during which the last data is transferred by the master across the bus, latency includes the time during which a master waits for the bus to become available (i.e., idle). As a result, latency may be reduced by allowing the bus to be idle.
In order for masters to share a common bus and have access to the slaves which are operationally attached to the bus, a bus arbiter may be used to arbitrate which master takes control of the bus at a particular time. Typically, each master which is operationally connectable to the bus has a request signal output which is used to indicate to the arbiter that the master is requesting bus access. The bus arbiter has a corresponding bus grant output which may be used to indicate to the master that the arbiter has granted the bus to the master. Once a master's request has been granted, the master may take control of the bus. Generally, the arbiter considers all pending requests, and if the bus is idle, makes a determination as to which master should receive access to the bus. During the time that a particular master has access to, or control of, the bus, the arbiter may prevent other masters from accessing the bus by not granting their requests for control of the bus until the first master has completed its transfer of data across the bus and relinquished control of the bus.
A number of different methods have been developed in an effort to address bus performance, including throughput and response time. Many of these methods are directed to the design of the bus arbiter and the manner in which the bus arbiter determines the "priority" level of the device seeking control of the bus. Various bus arbitration designs exist determining which master should be granted access, or control of, the bus.
For example, one design is directed to a "fixed" priority. In a "fixed" priority design, each request is assigned a priority level. The bus arbiter grants access to, or control of, the bus to the master having an active request and the highest priority among those masters submitting a request to control the bus.
By way of specific example, U.S. Pat. No. 5,528,767 to Chen describes a programmable multi-level bus arbitration apparatus for use in a data processing system. The arbitration apparatus of Chen provides a preemptive, interrupt driven method which permits specified masters to interrupt the control of the bus by a first master even though the first master has not completed its operation. Each master has a priority associated with it such that control of the bus is granted to a particular master device based on a pre-programmed priority scheme. In addition to the priority assigned to each master, an additional preemption priority permits certain masters to preempt the ongoing operations of a first master in order to take control of a bus away from the first master prior to the first master having completed its operations.
By way of further example, U.S. Pat. No. 5,481,680 to Larson et al. describes a programmable bus arbitrator which provides for historical feedback, and error detection and correction. The prioritization method employed by Larson et al. is that of a "fixed" priority which takes into account the history of the bus requests, as well as error detection and correction.
Various other methods exist for arbitrating requests by masters to control the bus. However, bus arbitration methods are generally designed to meet the requirements specific to the particular application to be implemented as well as the requirements of the bandwidth for each master that is operationally connectable to the bus.
The bus usage conditions in a system may vary over time, for example, light usage to heavy usage back to light usage. In addition, bus usage conditions may also vary as a result of the "system-on-a-chip" integrated circuit being employed in various applications. Consequently, it may be necessary to change the priority scheme for the arbitration unit, as well as the arbitration unit design itself, dependent upon the application. Moreover, it may be desirable to have a single bus arbiter to implement the arbitration for several different "system-on-a-chip" integrated circuits.
Although various arbitration schemes are presently used to control access to a common bus in multiple devices, these prior designs may not effectively address the need for improving maximum bus performance while accounting for changing applications in which a "system-on-a-chip" integrated circuit is employed and multiple systems being developed around a common bus. In order to improve maximum bus performance, the bus arbiter must be flexible in order to account for changing applications which are implemented using a "system-on-a-chip" integrated circuit, and multiple chips being developed to communicate via a common bus interface.